Summary
Placeholder for Amiya Gupta’s “Mastering the main thread” topic. The core interview angle is that smooth UX depends on keeping the browser main thread available for input, rendering, and layout.
Interview Points
- The main thread handles JavaScript, style calculation, layout, paint coordination, and many input events.
- Long tasks block input and make the app feel frozen.
- Break work into chunks, defer non-critical work, use workers where appropriate, and reduce unnecessary re-renders.
- Measure with INP, long tasks, flame charts, and real user monitoring.
2-3 Minute Interview Script
“When I talk about frontend performance at a senior level, I usually start with the main thread. The browser has to run JavaScript, process input, calculate styles, layout the page, and coordinate rendering. If my app monopolizes that thread, the user experiences jank even if the backend is fast.
My first principle is to reduce main-thread work: ship less JavaScript, avoid expensive render loops, virtualize large lists, debounce noisy input, and avoid layout thrashing. For unavoidable heavy work, I split it into smaller tasks or move it to a Web Worker.
I would measure this with performance traces and user-centric metrics like INP. I am looking for long tasks, repeated style/layout work, and interaction handlers that do too much synchronously.
The interview framing is simple: frontend performance is not only about load time. It is also about responsiveness after the app is loaded.”
Follow-Ups
- What is a long task?
- When would you use a Web Worker?